In modern 3D graphics systems, for each pixel within a polygon, it is possible to execute a program called a fragment shader (also referred to as a pixel shader). The fragment shader is used to determine the colour of a pixel based on input data related to that pixel and decisions made during the execution of the fragment shader code.
When developing a fragment shader program, it is important to be able to thoroughly test the operation of the fragment shader program in order to ensure it will operate as intended. Various issues are relevant when seeking to test the operation of a fragment shader program. Firstly, considering fragment shader optimisation, the time required to execute a fragment shader program is critical to maintaining a smooth 3D graphical experience, but the complexity of scenes, and thus shaders, can vary greatly. It would be desirable to provide a programmer with information about how the pixels of various rendered frames are processed by the fragment shader program, as this would provide the programmer with more details as to the execution time of the fragment shader program, allowing him/her to identify potential performance problems, for example particular values of input data which the shader program takes a relatively long time to generate the colour value for, and hence would allow the programmer to identify certain portions of the program shader code which require modification in order to alleviate the performance problems.
In addition, considering the issue of code coverage measurement, ensuring that all code paths in a program are tested is as important in fragment shaders as in any other programs. Accordingly, it would be desirable to provide a technique which during a testing operation generated information about which parts of the fragment shader code were executed during the generation of colour values for a sequence of input data, thereby identifying to the user any need for additional testing, or giving a user confidence in the correctness of their code by knowing that all parts of the fragment shader code have been tested.
Considering the issue of fragment shader debugging, the varying nature of 3D scenes makes debugging fragment shader programs difficult. For example, visual glitches may only be exhibited rarely by dynamically changing geometry. It would be desirable to provide a technique which during a debugging process provided information about the portions of fragment shader code that were used to generate the colour values for every pixel in a number of frames, since that would assist in the identification of sections of code that cause the bug, for example a visual glitch, thereby decreasing the time required to identify and fix the bug.
The article “Step-Through Debugging of GLSL Shaders” by Mark Hilgart, School of Computer Science, DePaul University, Chicago, USA, published at the website address http://facweb.cs.depaul.edu/research/techreports/TR06-015.pdf describes a rewriting method that enables step-through debugging on GLSL (OpenGL Shading Language) shader programs that are running in their intended application. Full-screen debugging is used first to identify interesting pixels, and then for those individual pixels of interest, the shader program code is stepped through line by line in order to understand the behaviour of the shader program code for those pixels. In particular, the described technique allows individual lines of code to be selected, and then the intermediate value of a selected variable at that line of code to be determined, with that intermediate value then being output as the colour value. Measures are described for enabling the remaining part of the shader program to be skipped to prevent the intermediate value of the selected variable being overwritten prior to output by the shader program.
Since the process described in the above article requires single stepping through the lines of code making up the fragment shader, it is inherently a very invasive debugging technique. Further, the described process is very labour intensive, since to understand how the input data for any particular pixel of interest is processed by the shader program, it is necessary to perform the single stepping process multiple times for multiple different lines of code in order to determine the intermediate values of selected variables at each of those lines of code. Furthermore, because of the invasive nature of the single stepping operation, it cannot be guaranteed that the code is operating in exactly the same way as it would if execution were not halted between each line of code.
The paper “A Hardware-Aware Debugger for the OpenGL Shading Language” by M Strengert et al, Graphics Hardware 2007, San Diego, Calif., 4-5 Aug. 2007, describes a similar step-through mechanism to that disclosed in the above mentioned “Step-Through Debugging of GLSL Shaders” article, but in particular is concerned with the identification of whether an identified branch was taken or not taken. In particular a method is described by which a single branch (or single interim value) may be examined by a user. It suggests that the user must pre-select the branch in which he/she is interested, nm the shader, and then examine the resulting pixel values in the image buffer. The values indicate whether the single branch was taken or not taken.
As with the earlier article, the technique described in this paper is very labour intensive and invasive, and would require multiple runs through the process to establish information about how the input data for any particular pixel of interest is processed by the shader program.
Accordingly, it would be desirable to provide a technique which could more readily provide information about the operation of the fragment shader for particular input data, with the information being gathered in a less invasive and less labour intensive manner.
In the general field of providing on-chip diagnostic capabilities within integrated circuits, GB-A-2,445,219 describes an integrated circuit having both a functional circuit and a diagnostic circuit. Further, a single interface controller is provided which monitors signals associated with the functional circuit and the diagnostic circuit, and controls selective communication of a diagnostic signal and a functional signal across a single signal interface in dependence upon the monitored signal. As a result, the integrated circuit thus has a single interface that removes the need for a set of dedicated trace diagnostic or test pins.